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A method, system and prog ram for redefining language 
dependent object definitions'as alTeutral set oi iniorma- 
ti onJEom which object support for any language, in- 
c ludingsupport between languages, is disclo sed. The 
in formation is parsed ana compiled to generate a bind- 
ings file which is input along with method information 
t o the target language compiler to create an object file. 
Th e object file is thereafter link edited to create exec ut- 
able programs. Target languages mclude C, Fortran, 
C++, COBOL or any other compiled language 
whether or not the particular language has object pro- 
gramming support. Messages are displayed on a display 
to aid a user. 
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SYSTEM FOR PRODUCING LANGUAGE 
NEUTRAL OBJECTS AND GENERATING AN 
INTERFACE BETWEEN THE OBJECTS AND 
MULTIPLE COMPUTER LANGUAGES 5 

This is a continuation of application Ser. No. 
07/805,668 filed Dec. 12, 1991 now abandoned. Co- 
pending applications include U.S. Pat. No. 5,339,438, 
"Version Independence for Object Oriented Pro- 10 
grams", U.S. Pat No. 5,361,350, "Object Oriented 
Method Management System and Software For Manag- 
ing Class Method Names in a Computer System", appli- 
cation Ser. No. 08/299,230, now allowed, which is a J5 
continuation of Ser. No. 07/805,777, now abandoned, 
and Ser. No. 07/805,778 now allowed, all the above 
applications were filed on the same date as the current 
application. 

FIELD OF THE INVENTION 20 

The invention generally relates to improvements in 
object oriented applications and more particularly to 
providing standard interactions between various lan- 
guages and systems. 25 

BACKGROUND OF THE INVENTION 

Among developers of workstation software, object- 
oriented programming (or OOP) is increasingly recog- 
nized as an important new programming technology. It 30 
offers expanded opportunities for software reuse and 
extensibility, with improved programmer productivity 
when compared to conventional software development 
paradigms. Even so, object-oriented technology has not 
effectively penetrated major commercial software 35 
products to date. In particular, operating-systems have 
hesitated to embrace the new technology. 

As with many new prograniming technologies, the 
early expressions of OOP concepts focused on the cre- 
ation of new languages and toolkits, each designed to 40 
exploit some particular aspect. So-called pure object- 
oriented languages, such as Smalltalk, presume a com- 
plete run-time environment (sometimes known as a 
virtual machine) because their semantics represent a 
major departure from traditional procedurally oriented 45 
system architectures. Hybrid languages such as C+ +, 
on the other hand, require less run-time support but 
sometimes result in tight bindings between programs 
that provide objects and the client programs that use 5Q 
them. Tight binding between object-providing pro- 
grams and their clients often require client programs to 
be recompiled whenever simple changes are made in 
the providing programs. Examples of such systems are 
found in U.S. Pat. No. 4,885,717; 4,953,080 and « 
4,989,132. 

Because different languages and object-oriented tool- 
kits emphasize different aspects of OOP, the utility of 
the resulting software is frequently limited in scope. A 
C++ programmer, for example, cannot easily use ob- ^ 
jects developed in Smalltalk, nor can a Smalltalk pro- 
grammer make effective use of C+ + objects. Objects 
and classes implemented in one language simply cannot 
be readily used from another. Unfortunately when this 
occurs one of the major benefits of OOP, the increased 65 
reuse of code, is severely curtailed. Object-oriented 
language and toolkit boundaries become, in effect, bar- 
riers to interoperability. 



SUMMARY OF THE INVENTION 

Accordingly, it is a primary objective of the present 
invention to redefine language dependent object defini- 
tions as a neutral set of information from which object 
support for any language, including support between 
languages, is available. 

These and other objectives, of the present invention 
are accomplished by the operation of an algorithm in 
the memory of a processor. A file containing a language 
neutral Object Interface Definition Language (OIDL) 
definition is recovered from a disk or other storage 
medium and input to a compiler resident in the memory 
of a computer. The compiler is a tool that converts the 
OIDL definition file into an intermediate form. The 
intermediate form is input to an emitter, which is a 
collection of utility routines that convert the intermedi- 
ate form of the file into binding that conform with the 
particular target language. The bindings are input to the 
particular target language compiler to generate object 
modules. Finally, object modules are link edited to 
create a loadable module. The loadable module is avail- 
able to any application program requiring its unique 
object functionality. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a personal computer 
system in accordance with the subject invention; 

FIG. 2 is a drawing of a SOM data structure in accor- 
dance with the subject invention; 

FIG. 3 is a drawing of a SOM class data structure in 
accordance with the subject invention; 

FIG. 4 is a flowchart depicting a language neutral 
object interface in accordance with the subject inven- 
tion; 

FIG. 5 is a flowchart depicting a link, load and execu- 
tion of an application using SOM objects in accordance 
with the subject invention; 

FIG. 6 is a flowchart depicting the creation of a new 
SOM class in accordance with the subject invention; 

FIG. 7 is a flowchart depicting the detailed construc- 
tion of a new SOM class in accordance with the subject 
invention; 

FIG. 8 is a flowchart depicting the detailed construc- 
tion of a new SOM generic class object in accordance 
with the subject invention; 

FIG. 9 is a flowchart depicting the detailed initializa- 
tion of a new SOM class object in accordance with the 
subject invention; 

FIG. 10 is a flowchart depicting the detailed initial- 
ization of a SOM class data structure with offset values 
in accordance with the subject invention; 

FIG. 11 is a flowchart depicting the detailed parent 
class shadowing of a statistically defined class hierar- 
chies in accordance with the subject invention; 

FIG. 12 is a flow diagram depicting the redispatch 
method in accordance with the subject invention; 

FIG. 13 is a flowchart depicting the detailed initial- 
ization of the offset value in a SOM class data structure 
for a single public instance variable in accordance with 
the subject invention; 

FIG. 14 is a flowchart depicting the detailed control 
flow that occurs when a redispatch stub is employed to 
convert a static method call into a dynamic method call 
in accordance with the subject invention; and 

FIG. 15 is a flowchart depicting the detailed control 
flow that initialize a method procedure table for a class 
in accordance with the subject invention. 
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The invention is preferably practiced in the context 
of an operating system resident on an IBM PS/2 com- 5 
puter available from IBM Corporation. A representa- 
tive hardware environment is depicted in FIG. 1, which 
illustrates a typical hardware configuration of a work- 
station in accordance with the subject invention having 
a central processing unit 10, such as a conventional 1° 
microprocessor, and a number of other units intercon- 
nected via a system bus 12. The workstation shown in 
FIG. 1 includes a Random Access Memory (RAM) 14, 
Reach Only Memory (ROM) 16, an I/O adapter 18 for 
connecting peripheral devices such as disk units 20 to 15 
the bus, a user interface adapter 22 for connecting a 
keyboard 24, a mouse 26, a speaker 28, a microphone 32, 
and/or other user interface devices such as a touch 
screen device (not shown) to the bus, a communication 
adapter 34 for connecting the workstation to a data 
processing network and a display adapter 36 for con- 
necting the bus to a display device 38. The workstation 
has resident thereon the OS/2 base operating system 
and the computer software making up this invention 
which is included as a toolkit. 

Object-Oriented Programming is quickly establishing 
itself as an important methodology in developing high 
quality, reusable code. The invention includes a new 
system for developing class libraries and Object-Ori- 
ented programs. TTus system is called the System Ob- 
ject Model (SOM). A detailed description of object 
oriented programming, SOM, and a comparison to 
other object-oriented languages is provided to aid in 
understanding the invention. 35 

INTRODUCTION TO OBJECT-ORIENTED 
PROGRAMMING 

A new development in the software community is 
Object-Oriented Programming. Object-Oriented Pro- 40 
gramming Languages (OOPL) are being used through- 
out the industry, Object-Oriented Databases (OODB) 
are starting widespread interest, even Object-Oriented 
Design and Analysis (OODA) tools are changing the 
way people design and model systems. 45 

Object-Oriented Programming is best understood in 
contrast to its close cousin, Structured Programming. 
Both attempt to deal with the same basic issue, manag- 
ing the complexity of ever more complex software sys- 
tems. Structured Programming models a system as a 50 
layered set of functional modules. These modules are 
built up in a pyramid like fashion, each layer represent- 
ing a higher level view of the system. Structured Pro- 
gramming models the system's behavior, but gives little 
guidance to modeling the system's information. 55 

Object-Oriented Programming models a system as a 
set of cooperating objects. Like Structured Program- 
ming, it tries to manage the behavioral complexity of a 
system. Object-Oriented Programming, however, goes 
beyond Structured Programming in also trying to man- 60 
age the informational complexity of a system. 

Because Object-Oriented Programming models both 
the behavioral and informational complexity of a sys- 
tem, the system tends to be much better organized than 
if it was simply well "structured". Because Object-Ori- 65 
ented systems are better organized, they are easier to 
understand, debug, maintain, and evolve. Well orga- 
nized systems also lend themselves to code reuse. 



Object-Oriented Programming envisions the dual 
issues of managing informational and behavioral com- 
plexity as being closely related. Its basic unit of organi- 
zation is the object Objects have some associated data, 
which are referred to as an object's state, and a set of 
operations, which are referred to as an object's meth- 
ods. A method is implemented by a subroutine. A class 
is a general description of an object, which defines the 
data representative of an object's state, and the methods 
for supporting the object. 

OBJECT-ORIENTED PROGRAMMING IN C 

Before examining SOM, consider Object-Oriented 
Programming in C; this will lead us naturally into the 
SOM philosophy. Consider a data structure definition 
containing information related to a generic stack. The 
data structure encompasses a series of functions de- 
signed to operate on a stack structure. Given a basic 
stack definition, multiple instances of this data structure 
may be declared within our program. 

A generic stack definition, in C, appears below: 



struct stackType { 
void *stackArray[STACK_SIZE3; 
int stackTop; 
}; 

typedef struct stackType Stack; 

A definition of a generic stack function appears next: 



Stack °crcate0; /* rn alloc and initialize a 

new stack. V . 
void *pop( /* Pop dement off stack. 

*/ 

Stack ft thisStack); 
void push( /* Push onto stack. */ 
Stack *thisStack, 
void *nextElement); 



Most C programmers can imagine how such functions 
would be written. The <push()> function, for exam* 
pie, appears below. 



void push(Stack "tbisStack, void *nextElement) 

this Suck- > 3tackArTay[thisS tack- > stackTop] = 
nextElement; 
thisStack-> stackTop+ + ; 

} 



A client program might use this stack to, say, create a 
stack of words needing interpretation: 



mainsO 
{ 

Stack 'wordStack; 
char, 'subject = "Emily"; 
char, *verb = "eats"; 
char *object = "ice cream"; 
char *nextWord; 
wordStack = createO; 
push(wordStack, object); 
pu$h(wordStack, verb); 
push(wordStack, subject); 
/• . . . V 

while (nextWord ~ pop(\vord Stack)) { 
printfC y.s \ n", nextWord); 

} 

} 
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This example can be used to review Object-Oriented 
Programming. A class is a definition of an object. The 
definition includes the data elements of the object and 
the methods its supports. A <stack> is an example of 
a class. A stack contains two data elements (<stackAr- 5 
ray> and <stackTop>), and supports three methods, 
<createO>, <push()>, and <popO>. A method is 
like a function, but is designed to operate on an object of 
a particular class. AN object is a specific instance, or 
instantiation, of a class. The object <wordStack> is an 10 
object of class < Stack >, or <wordStack> is an in- 
stance of a stack. 

Every method requires a specific object on which it is 
to operate. This object is called a target object, or some- 
times a receiving object. Notice that each method (ex- 15 
cept < crateO >) takes as its first parameter a pointer to 
the target object. This is because a program may have 
many objects of a given class, and each are potential 
targets for a class method. 

There are three important advantages of this type of 20 
organization. First, generic concepts are developed 
which can be reused in other situations in which similar 
concepts are appropriate. Second, self-contained code is 
developed, which can be fully tested before it is folded 
into our program. Third, encapsulated code is devel- 25 
oped in which the internal details are hidden and of no 
interest to the client. A client <main()> program need 
know nothing about the < Stack > class other than its 
name, the methods its supports, and the interfaces to 
these methods. 30 

COMPARISON TO C+ + 

Another beneficial comparison is between SOM and 
the most widespread Object-Oriented programming 
language, C+ +. SOM has many similarities to C+ +. 35 
Both support class definitions, inheritance, and overrid- 
den methods (called virtual methods in C+ +). Both 
support the notion of encapsulation. But whereas C+ + 
is designed to support stand-along programming efforts, 
SOM is focused on the support of commercial quality 40 
class libraries. Most of the differences between SOM 
and C++ hinge on this issue. C++ class libraries are 
version independent. When a new C+ + class library is 
released, client code has to be fully recompiled, even if 
the changes are unrelated to public interfaces. 45 

C++ supports programming in only one language, 
C++. SOM is designed to support many languages. 
Rather than a language, SOM is a system for defining, 
manipulating, and releasing class libraries. SOM is used 
to define classes and methods, but it is left up to the 50 
implementor to choose a language for implementing 
methods without having to learn a new language syn- 
tax, 

C++ provides minimal support for implementation 
hiding, or encapsulation. C+ + class definitions, which 55 
must be released to clients, typically include declara- 
tions for the private data and methods. In SOM, the 
client never has to focus on these implementation de- 
tails. The client need see only the <.sc> files, which 
contains only public information. C+ + also provides a 60 
limited method resolution function. SOM offers several 
alternatives, such as offset method resolution, name 
lookup resolution, and dispatch resolution. 

One other interesting difference between SOM and 
C+ + is in its notion of class. In C+ +, the class decla- 65 
ration is very similar to a structure declaration. It is a 
compile-time package with no characteristics that have 
significance at runtime. In SOM, the class of an object is 



an object. The class object is itself an instantiation of 
another class, called the metaclass. The class object 
supports a host of useful methods which have no direct 
parallels in C++, such as <somGetName0>, <som- 
GetParentO>, and <somFindMethodO>. 

INTRODUCTION TO SOM 

OS/2 2.0 includes a language-neutral Object-Ori- 
ented programming mechanism called SOM (for Sys- 
tem Object Model). Although it is possible to write 
Object-Oriented programs in traditional languages, 
such as the stack example, SOM is specifically designed 
to support the new paradigm and to be used with both 
procedural (or non Object-Oriented) languages and 
Object-Oriented languages. 

An important requirement of Object-Oriented pro- 
gramming is code reusability. Typically, code reusabil- 
ity is achieved through the use of class libraries. To- 
day's library technology is limited in that class libraries 
are always language specific. A C + + library cannot be 
used by a Smalltalk programmer and a Smalltalk pro- 
grammer cannot utilize a C++library. Clearly it is 
necessary to create a language-neutral object model, 
which can be used to create class libraries usable from 
any programming language, procedural or Object-Ori- 
ented. 

SOM introduces three important features lacking in 
most procedural languages. These are encapsulation, 
inheritance, and polymorphism (referred to here as 
"override resolution"). Inheritance refers to a technique 
of specifying the shape and behavior of a class (called a 
subclass) as incremental differences from another class 
(called the parent class or superclass). 

Encapsulation refers to hiding implementation details 
from clients. This protects clients from making changes 
in an implementation which could adversely affect the 
system. For example, in the stack example there was no 
protection afforded to the C code. Although clients did 
not need to know the internal data structures of the 
stack, there was no way to prevent clients from looking 
at such implementation details. We could discourage, 
but not prevent, clients from writing code which used, 
and possibly corrupted, internal stack data elements. 

Inheritance, or class derivation, is a specific tech- 
nique for developing new classes from existing classes. 
This capability provides for the creation of new classes 
which are more specialized versions of exiting classes. 
For example, we could create a <DebuggableStack>, 
which is like a <Stack> class, but supports further 
debugging methods, such as <peak0> for looking at 
the top value and <dump0> for printing a complete 
listing of the stack. 

Inheritance also provides code consolidation. So, for 
example, a class defining <GraduateStudent> and 
<UnderGraduateStudent>, can be consolidate into a 
third class, < Student >. We then define <GraduateS- 
tudent> and <UnderGraduate> as more specialized 
classes, both derived from the common parent < stu- 
dent >. 

Inheritance introduces some additional semantics. A 
specialized class is said to be derived from a more gener- 
alized class. The general class is called the parent class, 
or sometimes, the base class. The specialized class is 
called the child class, or sometimes, the derived class. A 
child class is said to inherit the characteristics of its 
parent class, meaning that any methods defined for a 
parent are automatically defined for a child. Thus, be- 
cause <GraduateStudent> and <UnderGraduateStu- 
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dent> are both derived from < Student >, they both 
automatically acquire any methods declared in their 
common parent. 

Override resolution refers to invoked methods being 
resolved based not only on the name of the method, but 
also on a class place within a class hierarchy. This al- 
lows us to redefine methods as we derive classes. We 
might define a <printStudentInfoO> method for <S- 
tudent> and then override, or redefine, the method in 
both <UnderGraduateStudent>, and <GraduateStu- 
dent>. Override resolution resolves based on the type 
of the target object. If the target object type is a < Stu- 
dent >, the < Student > version of <printStudentInf- 
o0> is invoked. If the target object type is a 
<GraduateStudent>, the <GraduateStudent> ver- 
sion of <printStudentInfoO> is invoked. 

DEFINING CLASSES IN SOM 

The process of creating class libraries in SOM is a 
three step process. The class designer defines the class 
interface, implements the class methods, and finally 
loads the resulting object code into a class library. Cli- 
ents either use these classes directly, make modifications 
to suit their specific purposes, or add entirely new 25 
classes of their own. 

In SOM, a class is defined by creating a class defini- 
tion file. The class definition file is named with an exten- 
sion of "esc". In its most basic form, the class definition 
file is divided into the following sections: 30 

1. Include section 

This section declares files which need to be included, 
much like the C <#include> directive. 

2. Class name and options 

This section defines the name of the class and declares 35 
various options. 

3. Parent information 

This defines the parent, or base, class for this class. 
All classes must have a parent. If a class is not derived 
from any existing classes, then it's parent will be the 40 
SOM defined class <SOMobject>, the class informa- 
tion of which is in the file < somobj.se >. 

4. Data Section 

This section declares any data elements contained by 
objects of this class. By default, data can be accessed 45 
only by methods of the class. 

5. Methods Section 

This section declares methods to which objects of 
this class can respond. By default, all methods declared 
in this section are available to any class client. The class 50 
definition file, < student. csc>, describes a non-derived 
< Student > class, and is set forth below. 
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-continued 



- returns the student id. 



How to Write a Method 

Class methods are implemented in the class method 
implementation file. Each method defined in the 
method section of the class definition file needs to be 
implemented. They can be implemented in any lan- 
guage that offers SOM support. C is used for an exem- 
plary language throughout the specification. However, 
one of ordinary skill in the art will realize that any 
programming language can be substituted. The student 
class method implementation file, <student.c>, is set 
forth below. 



Class Method Implementation File: <studentc> 
#define Student_Class_Source 
^include "student in" 
static void setUpStudent( 
student p somSelf, char *id, char 'name) 

{ 

StudentData 'somThis = 
Student GetDataCsomSdf); 
strcpy(-Jd, id); 
strcpy(_name, name); 

} 

static void printStudentInfo(Student °somSelf) 

StudentData °somThis = 

StudcntGetData(somSelf); 

printfnd : y.s \ n", —id); 

printf("Naine : % s \ n**, name); 

printfiCType : s \ n", 
_^etStudentTypc(somSelO); 
} 

static char *getStudentType(Student *somSelf) 
{ 

StudentData °somThis = 
StudentGetData(somSelf); 
static char *type = "student**; 
return (type); 

} 

static char *getStudentId(Student °somSelf) 
{ 



} 



StudentData °somThis » 
studentGetData(samSelQ; 
return (—id); 



Class Definition File: <student.c$c> 

include <somobj.sc> 

class: 

Student; 
parent 

SOMObject; 
data: 

char id[16]; /° student id */ 
char name[32]; /* student name V 
methods: 

void setUpStudent(char *id, char *name); 

- sets up a new student, 
void printStudentlnfoO; 

- prints the student information, 
char 0 getStudentTypeO; 

- returns the student type, 
char 'getStudentldQ; 



55 



60 



65 



Notice that the method code appears similar to stan- 
dard C. First, each method takes, as its first parameter, 
a pointer (<somSelf>) to the target object. This pa- 
rameter is implicit in the class definition file, but is made 
explicit in the method implementation. Second, each 
method starts with a line setting an internal variable 
named <somThis>, which is used by macros defined 
within the SOM header file. Third, names of data ele- 
ments of the target object are preceded by an under- 
score character The underscored name represents 
a C language macro defined in the class header file. 
Fourth, methods are invoked by placing an underscore 
in front of the method name. This underscored 
name represents a macro for message resolution and 
shields a programmer from having to understand the 
details of this process. 

The first parameter of every method is always a 
pointer to the target object. This is illustrated below in 
the method 



<printStudenUnfoO> which invokes the method 
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<getStudcntTypeO> on its target object. 
SOM compiler generated <$tudent.c> 
#defme Student_aass_Source 
#include "studentih" 
static void $etUp$tudent( 
Student *somSeif, char *id, char *name) 

StudentData *somThis = 
StudentGetData(somSelO; 

static void printStudemInfo(Student *somSe!0 

StudentData 'someThis = 
StudentGetData(somSelf); 

* . . . and so on for the other methods. V 
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MECHANICS OF USING SOM 

There are a set of files involved with each class which 
are discussed below. The files have different extensions, 
but all have the same filename as the class definition file, 
<Student> in our example. These files are described 
below. 

Student Class Files 25 

<student.csc> — This is the class definition file, as de- 
scribed earlier. 

< student. sc> — This is a subset of the class definition 
file. It includes all information from the <xsc> file 
which is public, including comments on public ele- 
ments. For the student example, <student.sc> 
would include everything from <student.csc> ex- 
cept the data section. This file is created by the SOM 
compiler. 

<studenth> — This is a valid C header file which con- 
tains macros necessary to invoke public methods and 
access public data elements of the class. This file will 
be included in any client of the class, and is created by 
the SOM compiler. 

<student,ih> — Similar to <student.h>, but it con- 
tains additional information needed for implementing 
methods. This is the implementor's version of the 
< .h> file, and must be included in the class methods 
implementation file. This file is created by the SOM 45 
compiler and should not be edited. 

< student, > — Contains the method implementations. 
Initially created by the SOM compiler and then up- 
dated by the class implementor. 

BUILDING SOM CLASSES FROM OTHER 50 
CLASSES 

There are two ways to use classes as building blocks 
for other classes. These are derivation (or inheritance) 
and construction. 55 

DERIVATION 

In this example, <GraduateStudent> is derived 
from < Student >, its base, or parent class. A derived 
class automatically picks up all of the characteristics of 60 
the base class. A derived class can add new functional- 
ity through the definition and implementation of new 
methods. A derived class can also redefine methods of 
its base class, a process called overriding. For example 
<GraduateStudent> adds <setUpGraduateStuden- 65 
t0> to those methods it inherits from > Student >. It 
overrides two other inherited methods, <printStuden- 
tInfoQ> and <getStudentType()>. It inherits without 



change <setUpStudentO> and <getStudentId()> 
from the < Student > base class. 

The class definition file for <GraduateStudent>, 
<graduate.csc>, is set forth below. 



Class Definition File: <graduatexsc> 

include <student.sc> 

class: 

Graduate Student; 
parent: 

Student; 
data: 

char thesis[128]; /* thesis title V 

char degree[16]; /* graduate degree type 

V 

methods: 
override printStudentlnfo; 
override getStudentType; 
void setUpGraduateStudent( 

char *id, char *name, char 'thesis, char 
^degree); 

The method implementation file, <graduate.c>, 
shown below. 



Class Method Implementation Hie: < graduate. c> 

#define GraduateStudent —Pass source 

#include "graduatcih" 

static void printStudeniInfo(GraduateStudent 

*somSelf> 

{ 

GraduateStudentData *someThis = 
GraduateStudentGetData(somSelO: 
parenL~printStudemInfo(som Self); 
printfC* Thesis : y.s. \ n", —thesis); 
printf(" Degree : % s \ n", _degree); 

} 

static char * get StudentType<Graduatc Student 

*somSelf) 

{ 

static char *type = "Graduate"; 
return (type); 

> 

static void setUpGraduateStudent( 

GraduateStudent *soxnSelf, char * id, char 
•name, 

^ char *thesis, char *degrcc) 

GraduateStudentData *someThis = 
GraduateStudentGctData(somSelf); 
_setUpStudent(somSelf,id,name); 
strcpy(_thesis, thesis); 
strcpy(_degree, degree); 



Often an overridden method will need to invoke the 
original method of its parent. For example, the <print- 
Studentlnfo0> for < GraduateStudent > first invokes 
the <Student> version of <printStudentInfoO> be- 
fore printing out the < GraduateStudent > specific 
information. The syntax for this is "< parent—Method- 
Name as can be seen in the <printStudentInfoO> 
method. 

A given base class can be used for more than one 
derivation. The class, <UnderGraduateStudent>, is 
also derived from < Student > . The class definition file, 
<undgrad.csc>, is set forth below. 



Class Definition File: <undgrad.csc> 

include < student sc> 

class: 

UnderGraduateStudent; 
parent: 

Student; 
data: 
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char date[16]; /* graduation date */ 
methods: 
override printStudentlnfo; 
override getStudentType; 
void setUpUndcrGraduateStudent( 
char »id, char 'name, char *date); 



void printCourselnfoO; 
- prints course information. 



The method implementation file, <undgrad.c>» is 
set forth below. 10 



Class Method Implementation File: <undgrad.c> 
# define UnderGraduateStudent__Class_Source 
#include "undgrad.ih" 

static void printStudentlnfo 15 
UnderGraduateStudent *scmSelf) 

{ 

UnderCraduateStudentData *someThis = 

UnderGraduateStudentGetData(somSelf); 
parent— printStudentInfo(somSeli); 

printfC 4 Grad Date : V.s \ n'\ —date); 20 

static char *getStudcntType(UnderGraduateStudent 

*somSelf) 

{ 

static char *typc = "UnderGraduate"; 
^ return (type); 25 

static void setUpUnderGraduateStudent( 

UnderGraduateStudent *somSelf,char *zd, char 
•name, char "date) 
< 

UnderGraduateStudentData "someThis « 30 

UnderGraduateSrudentGetData(somSelf); 

_5etupStudent(somSe]f,id,nanie); 
strcpy(— date, date); 



Often classes will want to take special steps to initial- 
ize their instance data. An instance of < Course > must 
at least initialize the < enrollment > data element, to 
ensure the array index starts in a valid state. The 
method <somlnit0> is always called when a new 
object is created. This method is inherited from <SO- 
MObject>, and can be overridden when object initial- 
ization is desired. 

This example brings up an interesting characteristic 
of inheritance, the "is-a" relationship between derived 
and base classes. Any derived class can be considered as 
a base class. We say that a derived class "is-a" base 
class. In the previous example, any <GraduateStu- 
dent> **is-a" < Student >, and can be used anyplace we 
are expecting a < Student >. The converse is not true. 
A base class is not a derived class. A < Student > can 
not be treated unconditionally as a <GraduateStu- 
dent>. Thus, elements of the array <studentList> can 
point to either <Student>s, a <GraduateStudent>s, 
or a <UnderGraduateStudent>s. 

The method implementation file for <Course>, 
<course.c>, is set forth below. 



The second technique for building classes is construc- 
tion. Construction refers to a class using another class, 
but not through inheritance. A good example of con- 
struction is the class <Course> which includes an 
array of pointers to < Student >s. Each pointer con- 
tains the address of a particular student taking the 
course. < Course > is constructed from < Student >. 
The class definition file for < Course > , < course. esc > , 
is shown below. 



35 
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Class Method Implementation File: <course,c> 

#defme Course— Class— Source 

#include <srudem.h> 

^include "course.ih" 

static void somlnit(course.*somSelf) 

CourseData 'someThis — CourseGetoata(somSelf); 

parent_somInit(somSelf); 

_code[0] = _title[D] = _instructor[0] = G; 

—credit = —capacity = —enrollment = 0; 

static void setUpCour$e(Course *somSelf, char 
'code, 

char °title, char "instructor, int credit, 
int capacity) 



Class Definition File: < course. csc> 

include < somobj.se> 

class: 

Course; 
parent: 

SOMObject; 
data: 

char code[8]; /" course code 

number V 
char title{32]; /* course title •/ 
char instructor[32]; /* instructor 

teaching V 
int credit; /* number of credits 
V 

int capacity; /» maximum number of 
seats */ 

Student _studentList[20]; /* enrolled student 
int enrollment; /* number of 
enrolled students */ 
methods: 
override somlnit; 

void sctUpCoursc(char *codc char *title, 
char 0 instructor, int credit, int capacity); 

- sets up a new course. 

int addStudent(Student °student); 

- enrolls a student to the course, 
void dropStudent(char "studentld); 

- drops the student from the course. 
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{ 

CourseData *someThis = CourseGetData(somSelf); 
strcpyC— code, code); 
strcpy(_title, title); 

strcpy( instructor, instructor); 

—credit « credit; 
—capacity «* capacity; 

static int addStudent(Cour3e 6 somSelf, Student 
°student) 

Coursedata ^somcThis = CourseGetData(somSelf); 
if(— enrollment > — —capacity) return (— 1); 
_ studentListl[_ enrollment + +] — student; 
return(0); 

} 

static void dropStudent(Course *somSelf, char 

*studentld) 

{ 

int i; 

CourseData *someThis = Cour$eOetData(somSelf); 
forG=0t i< —enrollment; i++) 
if(!strcnip(studentld, 
_ getStudentId<_ studentListp]))) i 
—enrollment-; 
forCt; i<_ enrollment; i++) 
—studentListp] = — studentListfl+l]; 
return; 

} 

} 

static void prmtCourseInfo(Course 'somSelf) 
int i; 

CourseData *somThis = CourseGetData(somSelf); 
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} 



printfC v.s v.s An", _code, —title); 
prinrf(" Instructor Name : vis \n*\ 
—instructor); 

printf( M Credit = */d, Capacity = Jfd, 
Enrollment = %d \n \n", 

—credit, — capacity, —enrollment); 
printf(" STUDENT LIST: \n \n"); 
for(i=0; i<_ enrollment; i-f-+) { 

_ prints tudentlnfb(— studentList[i]; 

printfC \n"); 

} 
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Notice in particular the method <printCourseInf- 
o()>. This method goes through the array <studentL- 
ist> invoking the method <printStudentInfoO> on 
each student. This method is defined for < Student >, 
and then overridden by both <GraduateStudent> and 
<UnderGraduateStudent>. Since the array element 
can point to any to these three classes, it is impossible at 
compile time to determine what the actual type of the 
target object is, only that the target object is either a 
< Student > or some type derived from < Student >. 
Since each of these classes defines a different <print- 
StudentInfoO> method, it is impossible to determine 
which of these methods will be invoked with each pass 
of the loop. This is all under the control of override 
resolution. 

THE SOM CLIENT 

To understand how a client might make use of these 
four classes in a program, an example is presented 
below in the file <main.c>. The example illustrates 
object instantiation and creation in SOM, and how 
methods are invoked. 



SOM client code: <main.c> 
•include <student.h> 
#include <course.h> 
#include <graduate.h> 
#inclDde <undgxad,h> 
raainO 
{ 

Course *course = CourseNew(); 
GraduateStudent °jane a» GraduatcStudcntNewO; 
UnderGraduateStudent "mark = 

UnderGraduateStudentNewO; 
— setUpCourse(course, "303", "Compilers ", 

"Dr. David Johnson", 3, 15); 

^&etUpGraduateStudent0anc J ' t 423538VJane 
Brown*', 

"Code Optimization". "PhJD.**; 
— setUpUnderGraduateStudent(mark T "399542*\ 

"Mark Smith", t, 12/17/92 ,t ); 
— addStudent(cour$e, jane); 
— addstudent(course, mark); 
_ printCourseInfo(course); 



A class is instatiated with the method <classNa- 
meNewO> ( which is automatically defined by SOM 
for each recognized class- Methods are invoked by 
placing an underscore in front of the method name. 
The first parameter is the target object. The remaining 
parameters illuminate additional information required 
by the method. When run, the client program gives the 
output shown below. 
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Client Program output 
303 Compilers 
Instructor Name : Dr. David Johnson 
Credit = 3, Capacity ~ 15, Enrollment = 2 
STUDENT LIST: 



Id 


: 423538 


Name 


: Jane Brown 


Type 


: Graduate 


Thesis 


: Code Optimization 


Degree 


: Ph.D. 


Id 


: 399542 


Name 


: Mark Smith 


Type 


: UnderGraduate 


Grad Date 


: 12/17/92 
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The client program output illustrates the override 
resolution at work in the different styles of displaying 
<UnderGraduate>s and < GraduateStudent >s. A 

< Course > thinks of itself as containing an array of 

< Student >s, and knows that any < Student > re- 
sponds to a <printStudentInfoO> method, But the 
<printStudentInfoO> method that an <UnderGradu- 
ate> responds to is different than the <printStuden- 
tlnfo0> method that a < GraduateStudent > responds 
to, and the two methods give different outputs. 

SOM Object Model 

FIG. 2 is a drawing of a basic SOM data structure in 
accordance with the subject invention. Label 210 is a 
state data structure for a particular object. The first full 
word at label 220 contains the address of the object's 
method procedure table label 240. The rest of the state 
data structure set forth at label 230 contains additional 
information pertaining to the object. The method pro- 
cedure table set forth at label 240 contains the address of 
the class object data structure 245 and addresses of 
various methods for the particular object 250 and 260. 
The address at 245 points to the class object data struc- 
ture 248. All objects that are of the same class as this 
object also contain an address that points to this method 
procedure table diagrammed at label 240. Any methods 
inherited by the objects will have their method proce- 
dure addresses at the same offset in memory as they 
45 appear in the method procedure table as set forth at 
label 240 of the ancestor class from which it is inherited. 

Address of the blocks of computer memory contain- 
ing the series of instructions for two of the method 
procedures are set forth at labels 250 and 260. Labels 
50 270 and 280 represent locations in a computer memory 
containing the series of instructions of particular 
method procedures pointed to by the addresses repre- 
sented by labels 250 and 260. 

The SOM Base Classes 

Much of the SOM Object Model is implemented by 
three classes that are part of the basic SOM support. 
Briefly these classes are: 

SOMobject— This class is the root class of all SOM 
classes. Any class must be descended from SOMOb- 
ject. Because all classes are descended from SOMOb- 
ject they all inherit and therefore support the meth- 
ods defined by SOMObject. The methods of 
SOMObject like the methods of any SOM class can 
be overridden by the classes descended from 
SOMObject. 

SOMClass — This class is the root meta class for all 
SOM meta classes. A meta class is a class whose 
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instances are class objects. SOMClass provides the 
methods that allow new class objects to be created. 
SOMClassMgr — This class is used to create the single 
object in a SOM based program that manages class 
objects. 

The three SOM base classes are defined below. 
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SOMObject 

This is the SOM root class, all SOM classes must be 
descended from < SOMObject >. < SOMObject > has 
no instance data so there is no per-instance cost to being 
descended from it 

SOMObject has the following methods: 
Method: somlnit 
Parameters: somSelf 
Returns: void 
Description: 

Initialize <self>. As instances of <SOMObject> 
do not have any instance data there is nothing to initial- ^ ^ ^ ^ ^ 
ize and you need not call this method. It is provided to 20 Returns "int 
induce consistency among subclasses that require ini- 
tialization. 

< somlnit > is called automatically as a side effect of 
object creation (ie, by <somNew>). If this effect is not 
desired, you can supply your own version of <som- 
New> (in a user-written metaclass) which does not 
invoke < somlnit >. 

When overriding this method you should always call 
the parent class version of this method BEFORE doing 
your own initialization. 
Method: somUninit 
Parameters: somSelf 
Returns: void 
Description: 

(Un-initialize self) As instances of < SOMObject > 
do not have any instance data there is nothing to un-ini- 
tialize and you need not call this method. It is provided 
to induce consistency among subclasses that require 
un-initializatkm. 

Use this method to clean up anything necessary such 40 
as dynamically allocated storage. However this method 
does not release the actual storage assigned to the object 
instance. This method is provided as a complement to 
<somFree> which also releases the storage associated 
with a dynamically allocated object. Usually you would 45 
just call <somFree> which will always call 
< somUninit >. However, in cases where <som- 
Renew> (see the definition of <SOMClass>) was 
used to create an object instance, <somFree> cannot 
be called and you must call <somUninit> explicitly. 

When overriding this method you should always call 
the parentclass version of this method AFTER doing 
your own un-initialization. 
Method: somFree 
Parameters: somSelf 
Returns: void 
Description: 

Releases the storage associated with <self>, assum- 
ing that <self> was created by <somNew> (or an- 



Parameters: somSelf 
Returns: Zstring 
Description: 

Returns a pointer to this object's class's name, as a 
NULL terminated string. It should not be necessary to 
override this method as it just invokes the class object's 
method (<someGetName>) to get the name. 
Method: someGetClass 
Parameters: somSelf 
Returns: SOMClass * 
Description: 

Returns this object's class object. 
Method: somGetSize 
Parameters: somSelf 
Returns: integer4 
Description: 

Returns the size of this instance in bytes. 
Method: somRespondsTo 
Parameters: somSelf, somld Mid 
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Description: 

Returns 1 (true) if the indicated method is supported 
by this object's class and 0 (false) otherwise. 
Method: somlsA 

Parameters: somSelf, SOMClass °Aclassobj 
Returns: int 
Description: 

Returns 1 (true) it <self>'s class is a descendent 
class of <Aclassobj> and 0 (false) otherwise. Note: a 
class object is considered to be descended from itself for 
the purposes of this method. 
Method: somlsInstanceQf 
Parameters: somSelf, SOMClass *Aclassobj 
Returns: bit 
Description: 

Returns 1 (true) if <self> is an instance of the speci- 
fied <Aclassobj> and 0 (false) otherwise. 

SOMObject methods that support dynamic object 
models. These methods make it easier for very dynamic 
domains to bind to the SOM object protocol boundary. 
These methods determine the appropriate method pro- 
cedure and then call it with the argument specified. The 
default implementation of these methods provided in 
this class simply lookup the method by name and call it. 
However, other classes may choose to implement any 
form of lookup they wish. For example, one could pro- 
vide an implementation of these methods that used the 
CLOS form of method resolution. For domains that can 
do so it will generally be much faster to invoke their 
methods directly rather than going through a dispatch 
method. However, all methods are reachable through 
the dispatch methods. SOM provides a small set of 
external procedures that wrap these method cells so 
that the caller need never do method resolution. 

These methods are declared to take a variable length 
argument list, but like all such methods the SOM object 
protocol boundary requires that the variable part of the 
argument list be assembled into the standard, platform- 



other class method that used <somNew>). No future 60 specific, data structure for variable argument lists be- 



references should be made to <self>. Will call 
< somUninit > or <self> before releasing the storage. 

This method must only be called on objects created 
by <somNew> (see the definition of <somClass>) 
and never on objects created by <somRenew>. 

It should not be necessary to override this method. 
(Override <someUnit> instead.) 
Method: somGetClassName 
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fore the method is actually invoked. This can be very 
useful in domains that need to construct the argument 
list at runtime. As they can invoke methods without 
being able to put the constructed arguments in the nor- 
mal form for a call. This is helpful because such an 
operation is usually impossible in most high lever lan- 
guages and platform-specific assembler language rou- 
tines would have to be used. 
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Note: different methods are defined for different re- Method: somDumpSelf 

turn value shapes. This avoids the memory management Parameters: somSelf, int level 

problems that would arise in some domains if an addi- Returns: void 

tional parameter was required to carry the return value. Description: 

SOM does not support return values except for the four 5 Uses <SOMOutCharRoutine> to write a detailed 

families shown below. Within a family (such as integer) description of this object and its current state. < level > 

SOM only supports the largest member. indicates the nesting level for describing compound 

Method: somDispatchV objects it must be greater than or equal to zero. All lines 

Parameters: somSelf, somld memodld, soralD descrip- in the description will be preceded by <2*level> 

tor, . . 10 spaces. 
Returns: void This routine only actually writes the data that con- 
Description: cems the object as a whole, such as class, and uses 

Does not return a value. <somDumpSelflnt> to describe the object's current 

Method: somDispatchL state. This approach allows readable description of 

Parameters: somSelf, somld methodld, somld descrip- 15 compound objects to be constructed. 

tor Generally it is not necessary to override this method, 
Returns: integer4 if it is overridden it generally must be completely re- 
Description: placed. 

Returns a 4 byte quantity in the normal manner that Method: somDumpSeiflnt 

integer data is returned. This 4 byte quantity can, of 20 Parameters: somSelf, int level 

course, be something other than an integer. Returns: void 

Method: somDispatchA Description: 

Parameters: somSelf, somld methodld, somld descrip- Uses <SOMOutCharRoutine> to write out the cur- 
tor rent state of this object Generally this method will need 
Returns: void * 25 to be overridden. When overriding it, begin by calling 
Description: the parent class form of this method and then write out 
Returns a data structure address in the normal man- a description of your class's instance data. This will 
ner that such data is returned. result in a description of all the object's instance data 
Method: somDispatchD going from its rood ancestor class to its specific class. 
Parameters: somSelf, somld methodld, somld descrip- 30 



tor 



SOMClass 



Returns: float8 This is the SOM metaclass. That is, the instances of 

Description: this class are class objects. When the SOM environment 

Returns a 8 byte quantity in the normal manner that is created one instance of this class with the external 

floating point data is returned. 35 name <SOMClassClassData.classObject> is created. 

SOMObject methods that support development This class object is unique because it is its own class 

The methods in this group are provided to support object. That is, SOMClassCIassData.classObject= = i. 

program development. They have been defined in such 3someGetClass(SOMClassClassData.classObject). This 

a way that most development contexts will find them class introduces the someNew and someRenew meth- 

easy to exploit However, some contexts may need to 40 ods that are used to create new instances of SOM ob- 

customize their I/O facilities. We have attempted to jects. somNew applied to <SOMClassClassData.clas- 

allow this customization in a very portable manner, sObject> produces a new class object which can then 

however not all contexts will be able to perform the be initialized to become a particular new class. SOM- 

customization operations directly because they require Class can be subclassed just like any SOM class. The 

passing function parameters. We chose this approach 45 subclasses of SOMClass are new metaclasses and can 

because it allows great platform-neutral flexibility and generate class objects with different implementations 

we felt that any provider of development support than those produced by <SOMClassClassData.clas- 

would find it reasonable to provide the customization sObject>. 

necessary for her/his specific development environ- SOMClass is descended from SOMobject. 

ment. 50 SOMClass defines the following methods. 

The chosen approach relies on a character output Method: someNew 

routine. An external variable, <SOMOutCharRou- Parameters: somSelf 

tine>, points to this routine. The SOM environment Returns: SOMAny * 

provides an implementation of this routine that should Description: 

work in most development environments (it writes to 55 Make an instance of this class. When applied to 

the standard output stream). A development context <SOMClassClassData.cIassObject>, or any other 

can, however, assign a new value to <SOMOutChar- metaclass object, this will produce a new class object; 

Routine > and thereby redefine the output process. when applied to a regular class object this will produce 

SOM provides no special support for doing this assign- an instance of that class. 

ment. 60 Method: somRenew 

Method: somPrintSelf Parameters: somSelf, SOMAny *obj 

Parameters: somSelf Returns: SOMAny * 

Returns: SOMAny * Description: 

Description: Make an instance of this class, but use the space 
Uses <SOMOutCharRoutine> to write a brief 65 pointed to by <obj> rather than allocating new space 

string with identifying information about this object. for the object. Note: no test is made to insure that 
The default implementation just gives the object's class <obj > points to enough space. <obj > is returned, but 

name and its address in memory. <self > is returned. it is now a pointer to a valid, initialized, object 
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Method: somlnitClass 

Parameters: somSelf, Zstring className, SOMAny 
*parentClass, integer4 instanceSize, int maxStatic- 
Methods, integer4 majorVersion, integer4 minorVcr- 
sion 

Returns: void 

Description: 
Initialize <self>. 

<parentClass> is the parent (or parent class) of this 
class, it may be NULL in which case it default to 
SOMObject (actually SOMObjectClassData.classOb- 
ject the class object for SOMObject). If a parent class is 
specified then it must have already been created as a 
pointer to its class object is required. 

<instanceSize> should be just the space needed for 
this class, it is not necessary to consider the parent 
class's (if any) space requirements. 

<maxStaticMethods> should be just the static meth- 
ods defined by this class, it is not necessary to consider 
the parent class's methods (if any), even if they are 
overridden in this class. 

<majorVersion> indicates the major version num- 
ber for this implementation of the class definition, and 
< minor Version > indicates the minor version number. 
Method: somClassReady 
Parameters: somSelf 
Returns: void 
Description: 

This method is invoked when all of the static initial- 
ization for the class has been finished. The default im- 
plementation simply registers the newly constructed 
class with the SOMQassMgr. Metaclasses may over- 
ride this method to augment the class construction se- 
quence in any way that they wish. 
Method: someGetName 
Parameters: somSelf 
Returns: Zstring 
Description: 

Returns this object's class name as a NULL termi- 
nated string. 
Method: somGetParent 
Parameters: somSelf 
Returns: SOMclass * 
Description: 

Returns the parent class of self if one exists and 
NULL otherwise. 
Method: somGetClassData 
Parameters: somSelf 
Returns: somClassDataStructure * 
Description: 

Returns a pointer to the static < className > Class- 
Data structure. 
Method: somSetClassData 
Parameters: somSelf, somClassDataStruture *cds 
Returns: void 
Description: 

Sets the class' pointer to the static <className>- 
ClassData structure. 
Method: somDescendedFrom 
Parameters: somSelf, SOMClass *Aclassobj 
Returns: int 
Description: 

Returns 1 (true) if <self> is a descendent class of 
<Aclassobj> and 0 (false) otherwise. Note: a class 65 
object is considered to be descended itself for the pur- 
poses of this method. 
Method: somCheckVersion 



Parameters: somSelf, integer4 majorVersion, integer4 

minorVersion 
Returns: int 
Description: 

Returns 1 (true) if the implementation of this class is 
compatible with the specified major and minor version 
number and false (0) otherwise. An implementation is 
compatible with the specified version numbers if it has 
the same major version number and a minor version 
number that is equal to or greater than < minorVer- 
sion >. The major, minor version number pair (0,0) is 
considered to match any version. This method is usually 
called immediately after creating the class object to 
verify that a dynamically loaded class definition is com- 
patible with a using application. 
Method: somFindMethod 

Parameters: somSelf, somld methodld, somMethod- 

Proc **m 
Returns: int 
Description: 

Finds the method procedure associated with <me- 
thodID> for this class and sets <m> to it 1 (true) is 
returned when the method procedure is directly call- 
able and 0 (false) is returned when the method proce- 
dure is a dispatch function. 

If the class does not support the specified method 
then <m> is set to NULL and the return value is 
meaningless. 

Returning a dispatch function does not guarantee that 
a class supports the specified method; the dispatch may 
fail. 

Method: somFindMethodOk 

Parameters: somSelf, somld methodld, SomMethod- 

Proc **m 
Returns: int 
Description: 

Just like <somFindMethod> except that if the 
method is not supported then an error is raised and 
execution is halted. 
Method: somFindSMethod 
Parameters: somSelf, somld methodld 
Returns: somMethodProc * 
Description: 

Finds the indicated method, which must be a static 
method defined for this class, and returns a pointer to its 
method procedure. If the method is not defined (as a 
static method or at all) for this class then a NULL 
pointer is returned. 
Method: somFindSMethodOk 
Parameters: SomSelf, somld methodld 
Returns: somMethodProc * 
Description: 

Just like < somFindSMethod > except that an error 
is raised if the method is not defined for this class. 
Method: somSupportsMethod 
Parameters: somSelf, somld Mid 
Returns: int 
Description: 

Returns 1 (true) if the indicated method is supported 
60 by this class and 0 (false) otherwise. 
Method: somGetNumMethods 
Parameters: somSelf 
Returns: int 
Description: 

Returns the number of methods currently supported 
by this class, including inherited methods (both static 
and dynamic). 

Method: somGetlnstanceSize 
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Parameters: somSelf 
Returns: integer4 
Description: 

Returns the total size of an instance of <self>. All 
instances of <self> have the same size. 5 
Method: somGetlnstanceOffset 
Parameters: somSelf 
Returns: integer4 
Description: 

Return the offset in the body part of this object for 10 
the instance data belonging to this class. 
Method: somGetlnstancePartSize 
Parameters: somSelf 
Returns: integer4 

Description: 15 

Returns the size in bytes of the instance data required 
for this class. This does not include the instance data 
space required for this class' ancestor or descendent 
classes. 

Method: somGetNumStaticMethods 20 
Parameters: somSelf 
Returns: int 
Description: 

Returns the number of static methods that this class 
has. This is used by a child class in initializing its method 25 
table. 

Method: somGetPClsMtab 
Parameters: somSelf 
Returns: somMethodTab * 

Description: 30 

Returns a pointer to the method table of this class's 
parent class. If this class is a root class (SOMObject) 
then NULL is returned. 
Method: somGetClassMtabe 

Parameters: somSelf 35 

Returns: somMethodTab * 

Description: 

Returns a pointer to the method table of this class. 
Method: somAddStaticMethod 

Parameters: somSelf, somld methodld, somld method- 40 
Descriptor, somMethodProc *method, somMethod- 
Proc *redispatchStud, somMethodProc *applyStub 

Returns: somMoffset 

Description: 

Adds/overrides the indicated method, returns the 45 
value that should be used to set the offset value in the 
class data structure for this method name. 

<methodDescriptor> is a somld for a string de- 
scribing the calling sequence to this method as de- 
scribed in <someGetNthMethodInfo> defined in the 50 
SOMObject class definition. 

< method > is the actual method procedure for this 
method. 

<redispatchStub> is a procedure with the same 
calling sequence as < method > that re-dispatches the 55 
method to one of this class's dispatch functions. 

< apply Stub > is a procedure that takes a standard 
variable argument list data structure applies it to its 
target object by calling < method > with arguments 
derived from the data structure. Its calling sequence is 60 
the same as the calling sequence of the dispatch meth- 
ods defined in SOMObject This stub is used in the 
support of the dispatch methods used in some classes. In 
classes where the dispatch functions do not need such a 
function this parameter may be null. 65 
Method: somOverrideSMethod 

Parameters: somSelf, somld methodld, somMethod- 
Proc *method 



Returns: void 
Description: 

This method can be used instead of < somAddStatic- 
Method > or <somAddDynamicMethod> when it is 
known that the class' parent class already supports this 
method. This call does not require the method descrip- 
tor and stub methods that the others do. 
Method: somGetMethodOffset 
Parameters: somSElf, somld methodld 
Returns: integer4 
Description: 

Returns the specified method's offset in the method 
procedure table assuming this is a static method, return 
0 if it was not. This value is used to set the offset value 
in this class data structure. It should only be necessary 
to use this method when a class used to define a method 
that it now inherits. 
Method: somGet Apply Stub 
Parameters: somSelf, somld methodld 
Returns: somMethodProc * 
Description: 

Returns the apply stub associated with the specified 
method. NULL is returned if the method is not sup- 
ported by this class. An apply stub is a procedure that is 
called with a fixed calling sequence, namely (SOMAny 
♦self, somld methodld, somld descriptor, ap_list ap) 
where <ap> is a varargs data structure that contains 
the actual argument list to be passed to the method. The 
apply stud forwards the call to tis associated method 
and then returns any result produced by the method. 

SOMClassMgr 

SOMClassMgr is descended from SOMObject 
SOMObject defines the following methods: 
Method: somFindClsInFile 

Parameters: somSElf, somld classld, int majorVersion, 

int minorVersion, Zstring file 
Returns: SOMClass * 
Description: 

Returns the class object for the specified class. This 
may result in dynamic loading. If the class already exists 
<file> is ignored, otherwise it is used to locate and 
dynamically load the class. Values of 0 for major and 
minor version numbers bypass version checking. 
Method: somFindClass 

Parameters: somSelf, somld classld, int majorVersion, 

int minorVersion 
Returns: SOMClass * 
Description: 

Returns the class object for the specified class. This 
may result in dynamic loading. Uses somLocateClass- 
File to obtain the name of the file where the class' code 
residues, then uses somFindClsInFile. 
Method: somClassFromld 
Parameters: somSelf, somld classld 
Returns: SOMClass * 
Description: 

Finds the class object, given its Id, if it already exists. 
Does not load the class. Returns NULL if the class 
object does not yet exist. 
Method: somRegisterClass 
Parameters: somSelf, SOMClass *classObj 
Returns: void 
Description: 

Lets the class manager know that the specified class is 
installed and tells it where the class object is. 
Method: somUnregisterClass 
Parameters: somSelf, SOMClass *classObj 
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Returns: int or into the object's state data structure set forth in FIG. 

Description: 2 at label 230. Similarly, labels 330 and 340 represent 

Unloads the class file and removes the class from the additional offsets into the method procedure table or 

SOM registry into its state data structure. For additional methods that 

Method: somLocateClassFile 5 are first defined in this first class or methods that are 

Parameters: somSelf, somld classld, int majorVersion, mentioned in the class release order section but defined 

int minorVersion by one of the class' ancestor classes, or public instance 

Returns: Zstring variables defined by this class, there are similar entries 

Description: m the class data structure representing offsets associated 

Real implementation supplied by subclasses. Default 10 w j t b fafc ^ signified by the elipse and "N+l" at 

implementation returns the class name as the file name. label 350. The additional entry is necessary because of 

Subclasses may use version number info to assist in thc flrst cntry represents a pointer to the class object 

deriving the file name. data structure 248 in FIG. 2. 

Method: somLoadClassFile The order of the values in the class data structure is 

Parameters: somSelf, somld classld, mt majorVersion, 15 determined by the order of the corresponding method 

int mmorVersion, Zstnng file or public i^^^ variable name in the release order 

Returns: SOMQass * section of ^ class OIDL fllc Method or public da ta 

Description: members defined in the class but not mentioned in the 

Loads the class code and initialize the class object. felease ofder are ordefed after ^ mentioned 

Method: somUnloadClassRle 20 fe ^ rdease or<Jer section ^ m the ordfir in wWch 

iSSSfbfi S ° MClaSS CkSSObj they appear in the class OIDL file. 

Description: Object Interface Definition Language (OIDL) 

Releases the class' code and destroys the class object. ^ redefines , dependent object 

Method: somGetlmtFunction 25 , f ., , ^.r-r ^ r l*^ 
n ♦ _ „e if definitions as a neutral set of information from which 
Parameters: somSelf „ _ ~ , . 
Returns* Zstrins object support for any language is provided. The neu- 
Descrintion- tT3 ^ set information is referred to as an Object Inter- 
Sup/hes the name of the initialization function in the ^J™E^ Language (OIDL) definition in SOM. 
class' code file. Default implementation returns (*SOM- 30 §pM ? mL £ ovldes basis *> r 8™**mg burning 
ClassInitFuncName)0 enable programming languages to use and 
Method* somMergelnto provide SOM objects and their definitions (referred to 
Parameters: somSef, SOMObject *targetObj * classes )- E** OIDL file defines the complete inter- 
Returns: void face to a class of ^OM objects. 

Description: 35 OIDL files come in different forms for different lan- 
Merges the SOMClassMgr registry information from S^ges. The different forms enable a class implementer 
the receiver to <targetObj>. <targetObj> is re- t0 specify additional language-specific information that 
quired to be an instance of SOMClassMgr or one of its allows the SOM Compiler to provide support for con- 
subclasses. At the completion of this operation, the structing the class. Each of these different forms share a 
<targetObj> should be able to function as a replace- 40 common core language that specifies the exact informa- 
ment for the receiver. At the end of the operation the tion ^at a must to ^ a class - 0,16 of toe 
receiver object (which is then in a newly uninitialized facilities of the SOM Compiler is the extraction of the 
state) is freed. Subclasses that override this method common core part of a class definition. Thus, the class 
should similarly transfer their sections of the object and implementer can maintain a language-specific OIDL 
pass this method to their parent as the final step. If the 45 file for a class, and use the SOM Compiler to produce a 
receiving object is the distinguished instance pointed to language-neutral core definition as needed, 
from the global variable SOMClassMgrObject, SOM- This section describes OIDL with the extensions to 
ClassMgrObject is then reassigned to point to <tar- support C-language programming. As indicated above, 
getObj > . OIDL files are compiled by the SOM Compiler to pro- 

50 duce a set of language-specific or use-specific binding 

Managing Object Names fij eSt 

The subject invention improves upon past object The SOM Compiler produces seven different files for 

oriented techniques of requiring unique external names the C language. 

for every method for a class by initializing the class A public header file for programs that use a class. Use 

method table at runtime via a special procedure associ- 55 of a class include creating instance objects of the 

ated with each class implementation and by collecting class, calling methods on instance objects, and sub- 

the set of method offsets into a single externally named classing the class to produce new classes, 

class data structure. This improvement reduces the A private header file, which provides usage bindings 

complexities of managing a large list of external vari- to any private methods the class might have, 

ables, reduces the problem of creating unique names 60 An implementation header file, which provides mac- 

(referred to as name mangling), reduces the memory ros and other material to support the implementa- 

requirements and reduces the load time of the generated tion of the class. 

execution module. An implementation template, which provides an out- 

FIG. 3 is a SOM class data structure in accordance line of the class' implementation that the class pro- 

with the subject invention. Label 310 represents a 65 vider can then edit 

pointer to the class object data structure set forth in A language-neutral core definition. 

FIG. 2 at 248. Label 320 represents an offset into the A private language-neutral core file, which contains 

method procedure table set forth in FIG. 2 at label 240 private parts of the class interface. 
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An OS/2 .DEF file that can be used to package the compiler. Even comments contained in passthru lies are 

class in the form of an OS/2 DLL. processed without modification. 

OIDL files can contain the following sections: n t S f 

Include section; section 

Class section; 5 This optional section lists the instance variables for 

Release Order section; this class. This section i s generally present only in the 

Metaclass section; language specific version of the class interface defini- 

Parent Class section; tion (a. CSC file). However, it must be present in the 

Passthru section; public form of the class interface definition if the class 

Data section; and 10 contains public instance variables. ANSI C syntac is 

Methods section. used t0 describe these variables. 

Include Section Methods Section 

This required section contains an include statement T* 1 * 5 optional section lists the methods supported by 

that is a directive to the OIDL preprocessor telling the 15 this class - ANSI c function-prototype syntax is used to 

compiler where to find the class interface definition for define the sequence to each method, 

this class' parent class, the class' metaclass if the class SOM Compiler 
specifies one, and the private interface files for any 

ancestor class for which this class overrides one or The SOM Compiler translates the OIDL source defi- 

more of its private methods. 20 mtion of a SOM class mt0 a set of oindin §s appropriate 

for a particular programming language. The SOM 
Class Section Compiler supplied with the OS/2.0 toolkit produces a 
This required section introduces the class, giving its com P lete set of bindings for the C programming lan- 
name, attributes and optionally a description of the class ^ u fjf e * 

as a whole 25 The compiler operates in two phases— a precompile 

phase and an emission phase. In the first phase a pre- 

Release Order Section compiler reads and analyzes a user-supplied class defini- 

This optional section contains a release order state- £°n ^ Produces intermediate output files containing 

ment that forces the compUer to build certain critical , n class ntformation, comments and passthru lines. 

, «, ^_ _ *t_ • ■ . . . , 30 In the second phase, one or more emitter programs run 

data structures with their items arranged m the order to roduce ^ e a TO riate Ian m e ^indhi files Tw 

specified. This allows the class interface and implemen- ^aaus i ~ fJL „ r * i_ 

/„. , , - .1 , . . .i. . additional programs serve as preprocessors for the 

tabon to be evolved witiiout requiring programs that SOM pleco ^ tvhasc _ The sequencing and execution 

use this class be recompiled of ^ ^ ^ ^ ^ ^ 

Release order applies to all method names and public ^ -j 

data items. If the release order of some method or public ^ t from the emitters> lus user . s lied lo ^ c 

data item is not specified, it will default to an implemen- for the class , mcthodS( m subsequently compiled by the 

JSSJ^S ? 145 oc< ? rrence m the C compiler and linked by the OS/2 linker to create a 

OIDL file. The introduction of new public data items or loadable motJule Loadable modu les can be packaged in 

methods might cause the default ordering of other pub- 40 self-contained files or placed in a DLL so the class can 

He data items or methods to change; programs using the be used from programs . 

class would then need to be recompiled. Referring to FIG. 4, control commences at terminal 

Metaclass section 400 311(3 flows directly into function block 404 where a 

SOM language neutral object interface definition 

This optional section specifies the class' metaclass, 45 (OEDL) 402 is input to the SOM OIDL compiler 404. 

giving its name and, optionally, a description of the The SOM OIDL compiler parses the object definitions 

reason for the metaclass, or other comments about its m OIDL into a canonical form 406 to simplify the code 

role in this class' interface. If a metaclass is specified, tis generation process as input to the target language emit- 

definition must be included in the include section. If no ter 410. The language emitter 410 generates language 

metaclass is specified, the metaclass of this class' parent 50 bindings 414 which include the class data structure 

class will be used. depicted in FIG. 3. Control flows to the language com- 

A class' metaclass can also be implicitly defined piler shown in function block 420 which receives addi- 

through the combined use of the class attribute in the tional inputs from the language applications 416 and the 

data section and the class attribute in the method sec- SOM bindings 412. The language compiler could be a 

tion. If either of these attributes are used, then the meta- 55 C, Fortran, Cobol or other compiler depending on user 

class section must be bypassed. In this case, the implied preference. Output from the language compiler is an 

metaclass will be a subclass of the metaclass of the par- object file 422 which can be link edited with the SOM 

ent class. runtime library for subsequent execution. 

Parent Class Section „ Fl ° r 5 58 a ^ chart d ^ a ** k >}°* ^ ^ ecu - 

60 tion of an application using SOM objects in accordance 

This required section specifies the class' parent class with the subject invention. Processing commences at 

by indicating the name and optionally a description of terminal 500 and immediately flows into function block 

the role of the parent class in this class' interface. 530 for a dynamic link and load of the SOM objects 510 

p , - . created in FIG. 4 at label 422 and the SOM run time 

rasstnru aecnon fi5 libfary 52Q ^ function block ^ the a p plica tion 

This optional section provides blocks of code to be is started, which invokes the creation of necessary 

passed by the compiler into various binding files. The classes and objects as set forth in function block 550 and 

contents of the passed information are ignored by the detailed in FIGS. 6, 7, 8, 9 and 10. Finally, the applica- 
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tion is executed as shown in function block 560 and the section titled "SOM Object Model" above. The 

control is terminated at terminal block 570. release order section of OIDL allows the class imple- 

. , , J - . ~ . mentor to insure that new method offset values are 

Version Independence For Object Oriented Programs added ^ ^ method offset va]ues for methods ^ 

This aspect of the invention generally relates to im- 5 ready defined in a class. The release order section in an 

provements in object oriented applications and more OIDL file also causes an entry to be retained in a class 

particularly solving problems arising from the indepen- data structure if one of the methods defined in the class 

dent evolution of object definition libraries and the is moved to a parent class as highlighted in FIG. 3. This 

computer applications that use them. entry is then initialized from the parent offset value by 

The version independence processing isolates the 10 a simple assignment statement that the OIDL compiler 

executable binary form of computer applications that adds the logic initializing the class data structure as 

use object definition libraries (also called object class described in FIG. 10. 

libraries) from certain changes in the implementations A similar problem arises with public instance data, 

or specification of the object definitions that naturally An application that accesses a public instance variable 

arise during the lifecycle of the libraries. Specifically, 15 contained in one of the application's object's state data 

the following changes can be made to an object defini- structure must do so via a offset into the object's state 

tion without compromising its use by the unmodified data structure. In the prior art, this offset was contained 

executable binary form of a computer application which in application's binary image. If this technique is em- 

dynamically loads the object definition each time the ployed, then the application's binary image must be 

application is executed; 20 regenerated (via recompilation) any time the offset 

1) add new methods to an object definition; changes due to a change in the size of one or more of the 

2) move the point of definition for a method from a object's ancestor classes' instance data requirements or 
child class to its parent class; due to changes in the object's own instance data layout. 

3) add to, delete from, or otherwise change the pri- In SOM this problem is solved by putting the offset 
vate instance data associated with an object defini- 25 for each public data variable in the class data structure 
tion; and detailed in FIG. 3 and the ensuing discussion. Each 

4) insert a new class definition into a class hierarchy. class data structure is initialized to contain the appropri- 
This processing is accomplished by the operation of ate offset values when the class object is initialized as 

an algorithm in the memory of a processor employing detailed in FIGS. 7 and 13. Thus, each time an applica- 

several techniques as follows. Method and instance 30 tion is executed all the offset values are recalculated 

offset are removed from application binary images. In based on the current definitions of the classes used by 

static object models, such as the one defined in C-h -h the application. 

an offset (an integer number) into a method procedure Remove object state data structure sizes from applica- 

table is used to select a method procedure for each tions' binary images 

particular method name. The offset depends on the 35 When new instances of objects are created, a correct 

number and order of the methods of the class the amount of computer memory must be allocated to hold 

method is defined in and the number of methods defined the object's state data structure. In the prior art, the size 

by its ancestors. of this block of memory was contained in an applica- 

This approach has the benefit of being a very fast tion's binary image. If this technique is employed, then 

form of method resolution. However, in the prior art 40 the application's binary image must be regenerated (via 

object models have placed these offsets in the binary recompilation) any time the size of the object's state 

images of the applications that used a particular object data structure changes. In SOM, this value is available 

class, resulting in the requirement to recompile the via a call to the object's class object and therefore need 

application whenever the offsets required a change. not be contained in an application's binary image. 

In SOM, the offsets associated with methods are 45 The techniques described above allow each of the 
collected into a single memory data structure for each four changes previously highlighted to occur with re- 
class, called the class data structure, detailed in the spect to class definitions used by an application without 
discussion of FIG. 3. This data structure is given an requiring that the application's binary image to be re- 
external name and its contents are referred to in applica- generated. 

tions. Each class data structure is initialized to contain 50 FIG. 6 is a flow chart depicting the creation of a new 

the appropriate offset values when a class object is SOM class in accordance with the subject invention, 

initialized as detailed in FIG. 10. Thus each time an Control commences at terminal 600 which flows imme- 

application is executed all the offset values are recalcu- diately into a test for a correct version number at deci- 

lated based on the current definitions of the classes used sion block 610 where a check is performed to verify the 

by the application. 55 correctness of the version number. If an incorrect ver- 

Note that any references in an application's binary sion number is detected, then a message is displayed in 
images to the values stored in the class data structure output block 612 and control is terminated at terminal 
containing offsets. However, these offsets can remain block 614. If a correct version number is detected, then 
constant across the four kinds of changes enumerated another test is performed at decision block 620 to deter- 
above. This is because the class data structure only 60 mine if the SOM class exists. If the SOM class exists, 
contains offsets for the methods defined in a particular then processing is returned at terminal block 622. 
class, not for offsets of methods inherited by the class. If the SOM class does not exist at decision block 620, 
Thus, new methods added to a class can have their then a test is performed at decision block 630 to deter- 
offsets added at the end of the class data structure with- mine if the SOM runtime environment is active. If it is 
out disturbing the positions of the offset values for 65 not active, then the SOM runtime environment is in- 
methods that were already defined in the class. voked at function block 632. Whether the SOM envi- 

The SOM Object Interface Definition Language ronment was initially present or not, control then flows 

(OIDL) contains a Release Order Section, discussed in to decision block 640 to check for an error in the SOM 
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environment at decision block 640. If an error is de- SOM runtime environment. Then, a test is performed to 

tected, then an appropriate message is presented at out- determine if the method has already been registered in a 

put block 642 and processing is terminated at terminal parent class in decision block 1030. If the method has 

block 644. If an error is not detected, then control been registered, then the method offset is overridden at 

passes to function block 650 where a default metaclass is 5 function block 1032 and control passes to decision block 

prepared. Next, a class is constructed in function block 1070. 

652 as detailed in FIG. 7. Finally, processing is returned if the method has not been registered with any parent 

at terminal block 660. class, then a test is performed to determine if the 

FIG. 7 is a flowchart depicting the detailed construe- method has been defined in the current class at decision 

tion of a new SOM class in accordance with the subject 10 block 1040. If the method has been defined, then the 

invention. Control commences at tenninal 700 and existing offsets are employed at function block 1042 and 

flows immediately into function block 710 where a control is passes to decision block 1070. If the method 

generic class object is created as detailed in FIG. 8. has not been defined, then memory is allocated and 

Next, the new generic class is initialized to default val- values ^ initialized in function blocks 1050 and 1060. 

ues at function block 720 and detailed in FIG. 9. Then, 15 In f unct j on block 1060 the offset is calculated by adding 

at function block 730, the instance data offset is initial- thc number of inherited static methods to the number of 

ized for the particular new class. Control flows to func- inhe rited static methods processed to date by the class. 

Don block 740 where the class data structure (FIG. 3) EmT processing * performed in decision block 1070, 

for the new class is miUalrzed by assigning values repre- ^ if M mQV ^ detccted) then ^ ap p ropr iate message 

senttng each static method for the new class as detailed 20 ^ &?Xzyea at output block 1072 ^ proce ssing termi- 

m f i-i i « ft j--. , nates at terminal block 1074. After error processing is 

At function block 750 760 and 770 the parent class is c0 leted> test is performed at bl * ck 

s^thedassdataismLt^edandtheclassKrepstered. W80 detemine if additiona] methods require 

^fflK^JSSS^n^r^ St^lt Pressing. If there are additional methods, then control 

ture as detailed in the discussion of FIGS. 2, 10 and 13. 25 . ° ^ . , n -« r . . 4 - 

Finally, control is returned at terminal 780. £»f to ^on block 1010 for the next iter^rf 

FIG. 8 is a flowchart depicting the detailed construe th * loo P- Otherwise, control flows to terminal 1090 

tion of a new SOM generic class object in accordance wnere contrm returns - 

with the subject invention. Control commences at ter- Parent Class Shadowing 

minal 800 and immediately flows into function block 30 _ . , 

810 where memory is allocated for the object. Then, a ^ c for Providing a dynamic insertion of a replace- 

test is performed at decision block 820 to determine ment P""* class referred to m object .programming as 

whether the memory was allocated. If an error is de- a P™? 4 class shadow, is detailed in this section of the 

tected, then an appropriate error message is displayed at invention. This processmg allows the statically com- 

output block 830 and processing is terrninated at termi- 35 P" ed dcfinitl0n of what parent class is linked to a partic- 

nal block 840. If no error is detected, then the default ular class at n" 1 ^ t0 De dynamically altered during 

values of the object are set at function block 850 and execution. The ability to insert a new parent class into a 

control is returned at terminal block 860. statically compiled class hierarchy offers more flexibil- 

FIG. 9 is a flowchart depicting the detailed initializa- itv to maintain and enhance existing code after it has 

tion of a new SOM class object in accordance with the 40 appeared in binary form. It also offers a new degree of 

subject invention. Control commences at terminal 900 freedom for customizing code without access to source 

and immediately enters a decision block 910 and a test is materials since this result can be achieved without 

performed to detect if the parent class of the new SOM recompilation. 

class object exists. If a parent class exists, then the par- Prior art systems have inherent limitations associated 

ent class is initialized in function block 912. Once the 45 with statically linking derived classes and their parent 

parent class is initialized, then memory for the class classes. These limitations include, computation of the 

name is allocated at function block 920. Next, a test is size of the derived object state data structure, initializa- 

perfonned again to detect if the parent class of the new ^ on of the derived method procedure table, and the 

SOM class object exists at decision block 930. inability to provide access to a parent class' methods 

If a parent class does not exist, then initial variables 50 fro °* within the derived class' methods (called parent 

are set to zero as shown in function block 932 and con- class resolution). 

trol passes to function block 970. If a parent class exists, The SOM object model removes these static refer- 
then the initial variables are updated based upon the ences by having all the parent class information avail- 
values from the parent class in function blocks 940, 950, able at runtime through the parent class object. Thus, 
and 960. Then, in function block 970, the version num- 55 when the derived class implementation needs informa- 
ber for the class is set and error processmg is performed tion about the size of the parent class' state data struc- 
in decision block 980. If an error is detected, then an ture, the addresses of the parent class* method proce- 
appropriate message is displayed at output block 982 dures, or access to the parent class' method procedure 
and processing terminates at terminal block 984. If no table (to support parent class resolution) an appropriate 
error is detected, then control is returned at terminal 60 call is placed to acquire the information from the parent 
block 990. class object. The detailed processing to obtain this in- 

FIG. 10 is a flowchart depicting the detailed initial- formation are given in FIGS, 7, 8, 9, and 10. 

ization of a SOM class data structure with offset values SOM introduces a class manager for every SOM 

in accordance with the subject invention. Control com- process. The class manager is responsible for keeping a 

mences at terminal block 100 and immediately flows 65 registry of classes. The class construction code gener- 

into function block 1010 where a loop commences with ated by the SOM compiler works with the class man- 

the acquisition of the next static method. In function ager to establish the relationship between a class and its 

block 1020, the new method id is registered with the parent class whenever a child class object is created. 
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The SOM class manager is an instance of a class which 
can be subclassed like any other SOM class. 

Derived classes establish a connection to their parent 
class object by making calls on the SOM Class Manager 
object. An application designer wanting to substitute an 5 
alternate class implementation for the original class 
implementation follows the following steps: 

1) Subclass SOMClassMgr providing a new set of 
application specific rules for determining a class object 
from a class name (i.e., changing the implementations of 10 
somClassFromld, somFindClass, and somFindClsIn- 
File) 

A simple and useful was to do this is to add a method 
to register a shadow class object under an existing class 
name and then return the shadow class object to the 15 
calling application in any subsequent calls to som- 
ClassFromld, somFindClass, or somFindClsInFile 
where the shadowed name is specified. 

2) Before creating any derived class objects that are 

to have a shadowed parent class object, create an in- 20 
stance of the new class manager class (as described in 
step 1 above), initialize it from the existing SOM- 
ClassMgr instance (via the somMergelnto method), and 
then replace the existing SOMClassMgr instance with 
the new class manager instance by overriding the ad- 25 
dress of the existing SOMClassMgr instance in the 
SOM runtime. 

3) Still before creating any derived class objects that 
are to have a shadowed parent class object, use the 
facilities of the application specified class manager ob- 30 
ject to register the shadow class objects. 

After the above three steps have been completed, 
derived class objects can be created. They will be linked 
to the appropriate parent shadow class objects. This 
will work because of the specific logic used to initialize 35 
a class object and link to its parent class object as de- 
picted in FIG. 11. This logic consists of two basic steps: 

1) First, a call is made to insure that he statically 
known parent class object has been created. This serves 
two important purposes: 40 

(a) It creates a static reference to the binary image of 
the statically known parent class definition, thus 
insuring that the parent class implementation will 
be linked into the binary image of the application. 

(b) It insures that the at least the statically known 45 
parent class object has been registered with the 
SOM class manager object before the next step 
occurs. 

If the statically known parent class object has already 
been created (say by an application following the shad- 50 
owing steps discussed above) then a second attempt at 
this time is ignored. 

2) Second, a call is made to the SOM class manager 
object to retrieve the address of the appropriate class 
object based on the name of the derived class' parent 55 
class. If the parent class has been shadowed then this 
call will return the shadow class object. 

The combination of the techniques and mechanism 
described above effectively isolate a derived class' bi- 
nary image from any dependency on the exact class of 60 
the class object that the derived class uses to extract 
parent class data from. 

Two restrictions must be observed when inserting a 
new class between a child class and its parent class. 
First, the insertion must be accomplished before any 65 
instances of the child class have been created. Second, 
the inserted class must also be an immediate child of the 
original parent class. Because the SOM class manager is 



used as an intermediary when establishing the relation- 
ships between classes at run time, even a statically 
linked class can be shadowed in this manner. 

FIG. 11 is a flowchart depicting the detailed parent 
class shadowing of a statically defined class hierarchies 
in accordance with the subject invention. Control com- 
mences at terminal block 1100 and immediately flows 
into function block 1110 where the statically defined 
parent class object is created. Next, the shadow parent 
class is created and used to override the statically de- 
fined parent class at function block 1120. Then, the 
child class is created as shown in function block 1130 
and the child class interrogates the SOM class manager 
to ascertain its current, rather than statically defined, 
parent class. Control returns at terminal block 1140. 

Redispatch Method Stubs 

A central aspect of object oriented programming is 
referred to as method resolution. This processing selects 
a particular method given an object, the method's id 
and the arguments passed to the method invocation. In 
many object models, such as the one used in C+ -f, 
method resolution consists of determining an offset into 
an object specific table of procedure entry points based 
on an analysis of the program's source code. This type 
of resolution is referred to in object models as static. In 
other object models such as the one used in Smalltalk, a 
more dynamic model is used that consists of using the 
name of the object to determine a specific method at 
runtime. In object models this is referred to as dynamic. 

The invention consists of a programming mechanism 
called redispatch stubs to ameliorate the difference be- 
tween static and dynamic models. A redispatch stub is a 
small procedure with an entry point that can be placed 
into a table of procedure entry points. The table of 
procedure entry points are used in a static object model 
as a substitute for the actual method entry point that is 
expected. The redispatch stub is generated automati- 
cally based on the requirements of the dynamic object 
model. The redispatch stub converts the call generated 
in the static object model into the form necessary in the 
dynamic object model and supplies any missing infor- 
mation in the process. Thus, if an object is accessed 
from a static object model that is provided by a dynamic 
object model, it can be represented to the static object 
model via a table of entry points which each indicate a 
particular redispatch stub. 

FIG. 12 is a flow diagram depicting the redispatch 
method in accordance with the subject invention. Label 
1200 is a state data structure for a particular object The 
first full word at label 1210 contains the address of the 
object's method procedure table label 1240. The rest of 
the state data structure is set forth at label 1230 contains 
additional information pertaining to the object. The 
method procedure table set forth at label 2140 contain- 
ing the addresses of various methods for the particular 
object All objects that are of the same class as this 
object also contain an address that points to this method 
procedure table diagrammed at label 1240. Any meth- 
ods inherited by the objects will have their method 
procedure addresses at the same offset in memory as 
they appear in the method procedure table as set forth 
an label 1240 of the ancestor class from which it is inher- 
ited. 

In the figure, label 1250 contains a pointer to a redis- 
patch stub 1270. A redispatch stub is a sequence of 
instructions that appear as a method to a client program. 
However, the instructions merely convert the method 
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call into a call to an object's appropriate dispatch func- dure returns its return value if any is returned to the 

tion as illustrated at label 1260. The address at label 1260 original caller of the redispatch stub at terminal block 

is a pointer to the object's dispatch function 1280. All 1460. The redispatch stub allows the original static 

SOM objects have a dispatch function. The dispatch method call to be converted to one of arbitrary dynam- 

function 1280 implements an algorithm to select a par- 5 ics without requiring any changes to the application 

ticular method based on the parameters passed by the . program that is manipulating the object 

redispatch stub. These parameters include the method's w , . •« , ^ < i T . • <• 

identifier, a string describing a set of arguments passed Method P 'ocedure Table Initialization 

to the identified method, and a data structure containing FIG. 15 is a flowchart depicting the detailed control 

the set of arguments. 10 flow that will properly initialize a method procedure 

table for a class that may change the association of 

Offset values method procedures to method during the execution of 

FIG. 13 is a flowchart depicting the detailed initial- an application using the class. Control commences at 

ization of the offset value in a SOM class data structure terminal block 1500 and immediately flows into func- 

for a single public instance variable. This logic sequence 15 tion block 1510 where space is allocated for the method 

is repeated for each public instance variable defined in a procedure table. Enough space is allocated to contain 

particular class (see the discussion of the OIDL Data an entry for the address of the class' object and each of 

Section above). Control commences at the terminal the method inherited or defined by the class in accor- 

block 1300 and immediately flows into the function dance with FIG. 7. Control then passes to function 

block 1310 where the offset of the instance variable is 20 block 1520 where each method entry in the method 

calculated by adding the instance variable's offset procedure table is replaced by its redispatch stub, 

within this class' object data to the offset of the begin- Redispatch stubs for inherited are determined by re- 

ning of this class' object state data within the object questing them from the class' parent class. Redispatch 

state data structure set forth in FIG. 2 at label 230. stubs for the class are generated by the SOM compiler 

The beginning of the class' object state data is deter- 25 and supplied to the class initialization procedure in the 

mined by adding up the sizes of each of this class' ances- calls to register each of the class' static method. Control 

tor classes' object state data. Control then passes to then passes to function block 1530 where the method 

function block 1320 when the calculated offset is stored procedure table entries for the class' dispatch function 

into the position in the class data structure as deter- are replaced by the actual address of the class' dispatch 

mined by the position of the public instance variable's 30 function (it is never correct to have a redispatch stub 

name in the OIDL files Release Order Section (see the address in a dispatch function slot as this would result in 

OIDL Release Order section above and FIG. 3 above). a infinite loop). Finally control passes to the terminal 

Control then flows to the terminal block 1330 and the block 1540 and processing is complete. 

process is complete. While the invention has been described in terms of a 

vaA* ti c ^ 5 preferred embodiment of a specific system environ- 

Redispatcn Mubs mentj those skmed in the m recosniz ^ that ^ inven . 

FIG. 14 is a flowchart depicting the detailed control tion can be practiced, with modification, in other and 
flow that occurs when a redispatch stub is employed to different hardware and software environments within 
convert a static method call into a dynamic method call. the spirit and scope of the appended claims. 
Control commences at the terminal block 1400 and 40 Having thus described our invention, what we claim 
immediately flows into the function block 1410 where as new, and desire to secure by Letters Patent is: 
the address of the redispatch stub is determined in the 1. A system for generating language specific interface 
normal static method resolution manner by getting the definitions for one or more of a plurality of program- 
address stored in the object's method procedure table at ming languages from a language neutral source pro- 
an offset contained in the appropriate class data struc- 45 gram, said interface definitions providing access to an 
ture at position determined when the class was defined. object-oriented programming object by said one or 

Control then passes to function block 1420 where the more of a plurality of programming languages, compris- 

redispatch stub is called exactly like it was the real static ing: 

method procedure. Function block 1430 depicts how (a) storage means for storing the language neutral 

the redispatch stub calls the object's dispatch method 50 source program; 

(using normal method resolution as described above). (b) means for processing the stored language neutral 

The redispatch stub adds the method's identifier and source program; 

descriptor to the call as required by the object's dis- (c) means for testing to determine for which of said 

patch method. These values are incorporated into the plurality of languages said language specific inter- 

redispatch function definition when it is generated by 55 face definitions are required; and 

the SOM OIDL compiler. (Note: as detailed in the (d) means for generating language specific interface 

definition of the SOMObject class above, all classes definitions from said processes language neutral 

must support dispatch methods). The object's dispatch source program for said determined languages, 

method procedure determines which actual method 2. The system of claim 1, wherein the interface defini- 

procedure should be called using an algorithm specific 60 tions for two or more languages are required, and said 

to the object's class as shown in function block 1440. means for generating generates two or more language 

SOM provides a default implementation of such an specific interface definitions, 
algorithm that looks the method's identifier up in a table 3. A computer implemented method for generating 
contained in the object's class object to determine the executable code from programs written in two or more 
address of a method procedure. Other object models 65 programming languages based on a single language 
might use other algorithms. Control then passes to func- neutral object definition, said two or more program- 
tion block 1450 where the method procedure deter- ming languages each having a syntax, the method corn- 
mined in block 1440 is called. When the method proce- prising the steps of: 
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storing said language neutral object definition, in a 
syntax different from said two or more programing 
language syntaxes; 5 

generating a plurality of interface definitions each 
following the syntax of one of said two or more 

10 

programming languages; 



36 

merging object implementation source code with one 
of said interface definitions to form an object im- 
plementing program; 

merging object use source code with a different one 
of said interface definitions to form an object using 
program; 

compiling said object implementing program with a 
first compiler to create executable code, and 

compiling said object use program with a second 
compiler to create executable code. 
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CERTIFICATE OF CORRECTION 


PATENT NO. 


5 , 428 ,792 Page 1 of 2 


DATED 




: June 27, 1995 


INVENTOR(S) 


: Mike H. Conner, Andrew R. Martin and 


It is certified that error^ppears irUhe ahmre-Ulentified patent and that said Letters Patent is hereby 


corrected as shown below: 


Col. 


2, 


line 54, delete "statistically" , insert 






— static&ily — ; 


Col . 


9, 


line 47, delete " < student . > ,f , insert — ^student . c>— ; 


col . 


14 


line 59, delete "SOMobject 1 , insert --SOMOh; ect-- ; 


col. 


17, 


line 1 ? delete "different", first occurrence, insert 






— Different--; 


Col . 


ie 


line 49 ; delete r SOMob:ect" , insert — SOMobject-- ; 


CO! . 


19 


line 44.. delete "SOKclassV insert --SOMCiass — : 


COI. 


21 


. line 34 , delete ,f so3iGetClassMtabe T , insert 






--scmGetdassMtab— ; 






line 42 , delete " *redispatchstuc" , insert 






— *redi5patchStut— ; 






line 43, delete -'somMof f set i: insert --scmKOf f set - - 


coi . 


22 


line 12- delets "return" . insert — returns--. 






line 35 : delete "icmSElf :: . insert — iomSelf - 






; line 12. delete ' : v/as ? . insert --way--; 






line 33, delete ,; he T: f insert —the--; 






line 56, delete ! ' xec::=^isni :: : insert --i- = cha::i£::i - *• 
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